Skip to content

Raise libsqlite3-sys dependency from 0.30 to 0.31 #3844

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Raise libsqlite3-sys dependency from 0.30 to 0.31 #3844

wants to merge 2 commits into from

Conversation

dtolnay
Copy link

@dtolnay dtolnay commented Apr 25, 2025

This makes it possible to use sqlx and the most recent versions of the cargo crate in the same dependency graph. Cargo depends on rusqlite 0.33 which uses libsqlite3-sys 0.31. Without this PR, this dependency graph doesn't work.

error: failed to select a version for `libsqlite3-sys`.
    ... required by package `sqlx-sqlite v0.8.5`
    ... which satisfies dependency `sqlx-sqlite = "=0.8.5"` of package `sqlx v0.8.5`
    ... which satisfies dependency `sqlx = "^0.8.5"` of package `repro v0.0.0`
versions that meet the requirements `^0.30.1` are: 0.30.1

the package `libsqlite3-sys` links to the native library `sqlite3`, but it conflicts with a previous package which links to `sqlite3` as well:
package `libsqlite3-sys v0.31.0`
    ... which satisfies dependency `libsqlite3-sys = "^0.31.0"` of package `rusqlite v0.33.0`
    ... which satisfies dependency `rusqlite = "^0.33.0"` of package `cargo v0.87.1`
    ... which satisfies dependency `cargo = "^0.87"` of package `repro v0.0.0`
Only one package in the dependency graph may specify the same links value. This helps ensure that only one copy of a native library is linked in the final binary. Try to adjust your dependencies so that only one package uses the `links = "sqlite3"` value. For more information, see https://doc.rust-lang.org/cargo/reference/resolver.html#links.

failed to select a version for `libsqlite3-sys` which could resolve this conflict

Is this a breaking change?

The libsqlite3-sys update: no, previous precedent is that these are semver-exempt and anyone using libsqlite3-sys through some other dependency needs to have pinned their sqlx version and be updating in lockstep.

sqlx/CHANGELOG.md

Lines 888 to 890 in 91d26ba

* Alongside this upgrade, we are now considering the linkage to `libsqlite3-sys` to be **semver-exempt**,
and we reserve the right to upgrade it as necessary. If you are using `libsqlite3-sys` directly or a crate that
links it such as `rusqlite`, you should pin the versions of both crates to avoid breakages from `cargo update`:

However, for this specific update, libsqlite3-sys requires a version of bindgen that only supports Rust 1.82+, and sqlx considers this a breaking change.

sqlx/FAQ.md

Lines 23 to 24 in 91d26ba

SQLx's MSRV is the second-to-latest stable release as of the beginning of the current release cycle (`0.x.0`).
It will remain there until the next major release (`0.{x + 1}.0`).

If a new major version of sqlx is not imminent, I am still interested in libsqlite3-sys 0.31 in sqlx 0.8 and can make it not a breaking change by improving bindgen to generate Rust 1.78-compatible code when run by a toolchain older than 1.82.

dtolnay added 2 commits April 25, 2025 15:09
@dtolnay
Raise required toolchain to Rust 1.82
e44d3c0 
This is required by bindgen 0.71, which is used by libsqlite3-sys 0.31.

    error: extern block cannot be declared unsafe
       --> target/debug/build/libsqlite3-sys-3da8b75ff8e55f52/out/bindgen.rs:521:1
        |
    521 | unsafe extern "C" {
        | ^^^^^^
@dtolnay
Update to libsqlite3-sys 0.31
7cc1206
@abonander abonander added the breaking:MSRV Requires waiting for an MSRV bump (see FAQ.md) label May 5, 2025
@abonander
Copy link
Collaborator

@dtolnay would it be acceptable to close this in favor of a bigger bump to 0.34/0.35: #3922 (comment)

@dtolnay
Copy link
Author

dtolnay commented Jul 7, 2025

With #3922 there is still no way to use a recent version of cargo and a recent version of sqlx in the same build graph. There is no version of cargo that is compatible with libsqlite3-sys 0.34 or 0.35. By skipping from 0.30 to 0.35 you would be leapfrogging all the versions that do not conflict with cargo. It would remain the case that the most recent published release of cargo that is possible to use in the same build graph as a published version of sqlx would be 3 Rust toolchain releases (4.5 months) out of date.

My preferred policy would be if sqlx could commit to hitting every libsqlite3-sys release, not skipping ahead more than one version at a time. For example you might publish sqlx 0.9.0 compatible with libsqlite3-sys 0.31, sqlx 0.9.1 compatible with libsqlite3-sys 0.32, sqlx 0.9.2 compatible with libsqlite3-sys 0.33, etc. Even if those are published on the same day within minutes of each other. This allows codebases constrained on libsqlite3-sys version (such as by cargo) to always be able to pin a sqlx version compatible with that.

@abonander
Copy link
Collaborator

What if we started using version ranges instead? There's generally never any changes that break our usage. Why does libsqlite3-sys always do a minor version bump, anyway?

@dtolnay
Copy link
Author

dtolnay commented Jul 7, 2025

In my experience range dependencies have been universally a bad idea in every project that has tried them. It leads to dependencies that flap unpredictably and uncontrollably between different versions when touching unrelated dependencies and when using cargo update --aggressive, leading to spurious confusing Cargo.lock diffs. In particular, Cargo's behavior is not that it resolves ranges to the largest version compatible with all the constraints from elsewhere in the build graph, which would be most people's expectation if they have not dealt with range-related problems before.

That said, I don't think my experience covers a version range for a dependency that uses links. I am willing to believe that in this case it would be okay because one can add their own (unused) dependency on a specific libsqlite3-sys version, and since only one version of this crate is allowed in the build graph by links, this deterministically controls the version of libsqlite3-sys that sqlx would pick up. With CI to verify sqlx really does work with every libsqlite3-sys version in the range, my guess is it would be okay.

@abonander
Copy link
Collaborator

Yeah, I think it should work fine because it's exactly what Diesel does: https://github.com/diesel-rs/diesel/blob/cdf7c51c35da7ebc6fb12e71857bfba8487c20cd/diesel/Cargo.toml#L53

@abonander abonander mentioned this pull request Jul 8, 2025
Open
@abonander
Copy link
Collaborator

Opened #3928

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
breaking:MSRV Requires waiting for an MSRV bump (see FAQ.md)
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@dtolnay @abonander